Typically, business transaction applications designed for use over the Internet or a local intranet are developed using a three-tier architecturally layered approach. The three-tier approach utilizes a User Presentation Layer, an Application Server layer, and a Data Source Layer.
First, the User Presentation Layer is designed to provide an end-user interface to the application. This interface is usually configured in a graphical format and is typically provided via a web browser. The browser itself has limited processing capabilities, and has the primary task of rendering visual images on virtual pages, known as web pages, to the end-user via a graphical display such as a computer monitor. The information for rendering these images are brief instructions provided in hypertext markup language (HTML). The browser receives these HTML instructions and renders the end-user interface. In business applications, the browser preferably displays individual transaction records in list, form, or tree formats, and such records may be comprised of one or more fields of information such as product, price, color, and availability.
The Application Server Layer uses an application server which provides all processing of business application data, including processing user input from the User Presentation Layer, performing required business logic, and updating or retrieving business transaction data from back-end data sources.
The Data Source layer is comprised of back-end database systems or services which have the responsibility of storing and managing business transaction data. This data is most often stored, or can be represented, in a tabular format, consisting of rows and columns. These rows and columns are ultimately presented to or received from the User Presentation Layer as records (rows) and fields (columns).
The typical design requires each individual Web page interface to be supported by one or more individual software components. These components respond to user events, perform business logic processing, and interact with various back-end database systems. Using commonly accepted object-oriented programming techniques, a developer must manually design and produce each of these components. In addition, the developer must define unique command keywords in the form of a URL (Uniform Resource Locator) to be sent by the Web Browser to the application server for interpretation and execution. These command keywords must be manually linked to specific software components and methods within those components.
Assume a user wants to write an application for displaying Order data from a single table, one record at a time. Traditional software techniques require that computer code be written to incorporate the following procedures.                Data access software code must be separately written for reading and writing from/to the database table, including code for capturing the field input from the page, and providing the field output for a given Order record.        The code for the actual JAVA Server Page which incorporates and utilizes the data access code to work with the Order data must be separately written.        Individual coding for defining any actions required by the page, and associated action keywords which tell the data access component which action to perform. Each of these action keywords must be defined by the developer, and interpreted by the data access component. Assuming a simple Ordering application, the minimum required actions for this screen are Insert (insert a new Order into the table), Update (update an existing Order), Delete (delete the Order), Next (show the next Order record from the Order List), Prior (show the prior Order record from the Order List).        
This must be done for each individual page in the entire application. As functionality and data increase, the amount of code which must be written to fully support the application increases dramatically. Accordingly, the drawbacks to the traditional approach, especially when considering large-scale applications, are as follows:                A) Such systems can require design and development of many hundreds of application software components. These components are time consuming to develop, and the resulting complexity from such vast numbers of objects makes support or modification of the application slow and error prone.        B) Developers must design and develop their own action keywords with which to control application function, a task that is tantamount to designing a simple programming language. This is both time-consuming and problematic, as naming conventions must potentially accommodate hundreds or thousands of such keywords.        C) Because each Web page is bound to a specific set of distinct software components, modifications in the user presentation mandate modifications to the underlying objects. These objects therefore limit application flexibility, and each change requires the supporting object program code to be modified, recompiled, tested and re-deployed to the application server. These tasks are error prone and cumbersome, especially within large developer groups.        D) User interface designs must be rigorously analyzed and detailed prior to development, as the dependency between Web pages and supporting software objects is both rigid and complex. This constraint limits the flexibility of the user presentation, extending delivery times required for accommodating user requests.        
In short, the generally accepted object-oriented design concepts result in highly complex applications, composed of hundreds or thousands of software components, and thus require extensive design and development resources to construct, debug, maintain and enhance.
One proposed solution to the problem is to rely on a code generation program to automatically produce a majority of the components in such a system based on business rules specified by the developer. While such a program can output machine generated software components which approximate some portion of the system requirements, developers must still examine, modify and maintain many of these components to meet specific business processing needs. Further, such a solution does nothing to reduce the complexity and number of required software components, and in fact can result in an even greater number of components which are inherently less efficient than those designed and developed by software engineers.